home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
misc
/
merit
/
1991
/
91_016r.txt
< prev
next >
Wrap
Text File
|
1991-05-05
|
31KB
|
890 lines
Network Working Group April 1991
Internet-Draft M.T. Rose
Internet Draft CO/CL Interworking -- Introduction Apr 91
An Approach to CO/CL Interworking --
Part I: Introduction
Wed Apr 17 09:12:55 1991
CO/CL Interworking Workshop
July 24-26, 1990
April 5, 1991
M.T. Rose (editor)
Performance Systems International, Inc.
mrose@psi.com
1. Status of this Memo
An approach to the OSI CO/CL Interworking problem is proposed.
This approach has been developed at the request of the FNC and
RARE communities, but may be applicable to other communities.
This memo does not explicitly specify a standard, however, it
may form the basis for policy within the FNC, RARE, or other
communities.
Distribution of this memo is unlimited. Questions should be
directed to the editor.
M.T. Rose (editor) [Page 1]
Internet Draft CO/CL Interworking -- Introduction Apr 91
2. Introduction
The OSI transport service[1] may be realized through a variety
of transport/network protocol combinations. Regrettably, few
of the combinations actually interoperate with each other. As
such, even if all OSI-capable end-systems enjoyed full-
connectivity, they would not be able to uniformly
interoperate.
This memo examines the problem and proposes an approach in
order to develop solutions to this problem. In particular,
the short-term focus of this work draws on early experience in
the area of both OSI realization and transition and
coexistence between OSI and the Internet suite of protocols.
In contrast, the long-term focus of this work utilizes a
mature OSI infrastructure.
This memo begins by introducing a model of a "pure" OSI end-
system and how it establishes a transport connection to
another end-system. Next, the practical problems of realizing
this model are presented. Following this, a two-phase
approach towards a solution is examined. Finally, the
implications of that solution are explored.
The reader is assumed to have a basic familiarity with the OSI
end-to-end services.
2.1. An Aside
This memo deals with the OSI transport service. A fundamental
assumption of the presentation is that the two end-systems are
attempting to interoperate using a common application
protocol, e.g., the OSI Directory (X.500).
This memo is explicitly uninterested in the problem of
achieving interoperability between two end-systems using
different application protocols, e.g., one end-system using
the OSI file service (FTAM) and the other end-system using the
Internet file transfer protocol (FTP). In this case, an
application gateway technology should be used.
In brief, this memo is interested only in environments in
which the application is identical on both end-systems.
M.T. Rose (editor) [Page 2]
Internet Draft CO/CL Interworking -- Introduction Apr 91
3. Application Use of End-to-End Services
This section introduces a conceptual model as to how OSI
transport connections might be established.
When an OSI application wishes to establish an association,
that application identifies an application entity that
provides the service desired for communication. The
application entity identification is given to the OSI
Directory and the corresponding presentation address is
retrieved. This presentation address consists of a
presentation selector, session selector, and a transport
address. When the association is to be initiated, there are
two parameters of interest to us: the presentation address as
provided by the Directory, and the communications quality-of-
service (QoS) as desired by the application. The first
identifies the location of the desired service, the second
identifies the characteristics of the association to be
established with that service.
After passing through the highest layers, the transport
address, consisting of a transport selector and one or more
network addresses, is given to the transport service, and a
request is made to establish a transport connection.
The local transport entity now follows three steps in order to
establish the connection:
(1) The entity looks at each network address and decides
which mode of network service, connection-oriented (CONS)
[2] or connectionless-mode (CLNS) [3], will be used for
the address. At present, there is no standard method nor
set of agreements for making this determination; in some
implementations, the determination is made on the basis
of NSAP prefixes, with this information being configured
by the system administrator.
Based on the derived network service and the desired QoS,
the local transport entity selects a transport protocol.
That is, for each network address in the transport
address, the entity selects a combination of a transport
protocol and network service, referred to as a TS-stack,
that will be used to establish a transport connection to
that address.
M.T. Rose (editor) [Page 3]
Internet Draft CO/CL Interworking -- Introduction Apr 91
(2) The network addresses are then ordered, based on the
desired QoS and the "closeness" of the network address.
Again, this decision is a local matter.
Suppose, for example, a transport address contained two
network addresses, each implying use of a CONS. One of
the network addresses might reside in a private network,
whilst the other address resides in a public data
network. For economic reasons, the local transport
entity might prefer to try the private network first.
(3) For each network address, the local transport entity
starts the protocol machine for the TS-stack associated
with that address. This results in a transport protocol
and underlying network service being invoked. Once a
transport connection is established, the remaining
network addresses are ignored.
3.1. Emulation of OSI End-to-End Services
It should be noted that a TS-stack can be realized using non-
OSI protocols. For example, the RFC1006 method defines a
transport service convergence protocol which smoothes over the
differences in the services offered by the OSI transport
service and the TCP [4]. This is known as the RFC1006/TCP
TS-stack.
If such a protocol is properly defined, then the OSI upper-
layer infrastructure (session, presentation, and application)
running above is unable to tell that it is not running in a
"pure" OSI environment.
Of course, one must also have a means for storing such
addresses in the OSI Directory. Kille has defined an Interim
approach[5], which, among other things, allows addresses
associated with the RFC1006/TCP TS-stack to be encoded as real
OSI network addresses. Using such an approach, these
addresses may be transparently stored in the OSI Directory.
Further, one can easily examine such an address and determine
the appropriate TS-stack to use when initiating a connection.
The use of the RFC1006 method is particularly interesting as
it allows use of the powerful OSI applications on the stable
end-to-end services offered by the Internet suite of
M.T. Rose (editor) [Page 4]
Internet Draft CO/CL Interworking -- Introduction Apr 91
protocols.
M.T. Rose (editor) [Page 5]
Internet Draft CO/CL Interworking -- Introduction Apr 91
4. Problems in Realizing the Model
This memo is concerned with one class of problem which might
arise as the local transport entity acts as described above.
Looking back at the first step, the entity must establish a
binding between each network address and a TS-stack.
Suppose that the end-system on which the transport entity
resides offers only a subset of the TS-stacks implied by the
transport address. For example, suppose that there are four
network addresses, two requiring use of the CONS, and the
other two requiring use of the CLNS. If initiating end-system
supports only the CONS, then any network address which
requires use of the CLNS can not be reached from that end-
system. That is, the local transport entity must intersect
TS-stacks derived for the network addresses with the TS-stacks
supported by the local end-system. Thus, in this first step,
only a subset of the network addresses may be suitable for use
on the initiating end-system.
The problem, of course, is that the intersecting subset may be
empty! From a "purist" perspective, interworking can not
occur in this case, and the local transport entity will
immediately generate a transport disconnect.
In exploring this problem, it is natural to ask how often this
situation arises. The answer is simple: in a homogeneous OSI
environment, say a CL-mode LAN (e.g., an 8802 network) or a
CO-mode WAN (e.g., an X.25 network), this problem should never
arise. However, whenever different OSI environments are
interconnected, this problem usually results.
Consider the simplest example: a site has an 8802-based
subnetwork running CLNP, TP4, and OSI applications. All of
the end-systems in that environment implement the TP4/CLNS
TS-stack. Some time later, one of the end-systems on that
subnetwork is attached to an X.25-based subnetwork. For
brevity, term this end-system "dual". On the dual end-system,
another TS-stack is added, e.g., TP0/CONS. The other end-
systems are not modified since they continue to have a single
point of attachement, which supports only the CLNS. Now,
observe that within the original 8802-based subnetwork, all
end-systems, including dual, continue to interoperate with one
another. Also observe that the dual end-system can
interoperate with any other end-system directly attached to
M.T. Rose (editor) [Page 6]
Internet Draft CO/CL Interworking -- Introduction Apr 91
the X.25-based subnetwork. However, note that it is unlikely
that any of the other end-systems in the 8802-based subnetwork
can interoperate with an arbitrarily chosen end-system in the
X.25-based subnetwork.
In order to appreciate the basis for the approach which
follows, it is necessary to introduce one additional term, the
OSI community. An OSI community is a collection of end-
systems connected together and sharing a common TS-stack.
That is, more technically, a community is defined in terms of
connectivity and a TS-stack.
So, given two OSI communities which have an intermediate-
system in common, but have different TS-stacks, can arbitrary
end-systems in those two communities interoperate?
First, note that the CONS and the CLNS do not interwork.
Hence, if the two communities support only different modes of
network service, then they can not interoperate.
Second, note that even if two communities share a network mode
in common, then all intermediate-systems must also support
that same network mode.
For situations in which direct interworking is not possible, a
transport-layer relaying approach has been suggested. Because
they exist outside the scope of OSI, the theory and practice
of transport-layer relays are poorly-understood.
M.T. Rose (editor) [Page 7]
Internet Draft CO/CL Interworking -- Introduction Apr 91
5. Transport-Service Bridges
The motivation behind transport-layer relaying is to observe
that all TS-stacks share one thing in common: they all offer
the OSI transport service. Thus, a new entity is introduced,
residing above the transport service, termed a transport
service bridge (or TS-bridge), or CO/CL-gateway. The TS-
bridge is purposefully naive as to TS-stacks or the transport
protocols and network services which compose them. Rather,
the TS-bridge knows only how to invoke the OSI transport
service, which is offered by all TS-stacks, regardless of
their composition.
In pictorial form:
+------------------------------------+
| |
| |
| +----------------------------+ |
| | TS-bridge | |
| +----------------------------+ |
| | | |
| | | |
| | | |
+----------+ | +----------+ +----------+ | +----------+
| | | | | | | | | |
| TS-stack | | | TS-stack | | TS-stack | | | TS-stack |
| #1 | | | #1 | | #2 | | | #2 |
| | | | | | | | | |
+----------+ | +----------+ +----------+ | +----------+
| | | | | |
| | | | | |
| +------------------------------------+ |
| | | |
| | | |
+------------------+ +------------------+
The function of the TS-bridge is simple: upon receiving a
transport connection indication (a T-CONNECT.INDICATION
primitive), the TS-bridge initiates a second transport
connection, to the actual destination address. If the second
connection is established, then the TS-bridge accepts the
first transport connection. From this point on, any data
received on one transport connection is simply sent on the
M.T. Rose (editor) [Page 8]
Internet Draft CO/CL Interworking -- Introduction Apr 91
other transport connection. When a disconnect occurs on one
of the transport connections, the TS-bridge disconnects the
other transport connection.
Of course, if the second connection is not established, then
the TS-bridge will simply disconnect the first transport
connection.
5.1. State Machine
The TS-bridge starts in the IDLE state. The events and
actions below refer to the service primitives defined in [1].
Further, "A" refers to the initial transport connection, and
"B" refers to the second transport connection.
STATE EVENT --> ACTION GOTO
----- -------------------- -------------------- ----
IDLE A: T-CONNECT.IND B: T-CONNECT.REQ WAIT
WAIT B: T-CONNECT.CNF A: T-CONNECT.RSP DATA
WAIT B: T-DISCONNECT.IND A: T-DISCONNECT.REQ IDLE
WAIT A: T-DISCONNECT.IND B: T-DISCONNECT.REQ IDLE
DATA A: T-DATA.IND B: T-DATA.REQ DATA
DATA B: T-DATA.IND A: T-DATA.REQ DATA
DATA A: T-EXP-DATA.IND B: T-EXP-DATA.REQ DATA
DATA B: T-EXP-DATA.IND A: T-EXP-DATA.REQ DATA
DATA B: T-DISCONNECT.IND A: T-DISCONNECT.REQ IDLE
DATA A: T-DISCONNECT.IND B: T-DISCONNECT.REQ IDLE
Note that if any errors occur (e.g., interface errors), then
both transport connections are disconnected.
Note that the TS-bridge is bi-directional: an end-system in
any community may initiate a connection to an end-system in a
different community, providing that the TS-bridge is a member
of both communities.
5.2. Parameters for the second connection
There are a few other special interactions performed by the
TS-bridge when establishing the second transport connection.
These all affect the parameters given to the T-CONNECT.REQ
M.T. Rose (editor) [Page 9]
Internet Draft CO/CL Interworking -- Introduction Apr 91
primitive.
(1) It should be noted that there are very slight differences
in the total service offered by some TS-stacks. In
particular, a TS-stack containing TP0 does not support
user-data during connection establishment. As such, if
the T-CONNECT.IND primitive for "A" contains user-data,
then the TS-bridge disconnects the transport connection.
Similarly, if the T-CONNECT.CNF primitive for "B"
contains user-data, then the TS-bridge disconnects both
transport connections.
(2) In addition, a TS-stack containing TP0 does not support
the expedited data facility. As such, the TS-bridge must
be prepared to down-negotiate use of this facility.
Basically, when forming the T-CONNECT.REQ primitive for
"B", the TS-bridge copies the value of the expedited data
facility parameter from the T-CONNECT.IND primitive for
"A". Similarly, when forming the T-CONNECT.RSP primitive
for "A", the TS-bridge copies the value of the expedited
data facility parameter from the T-CONNECT.CNF for "B".
5.3. Impact of TS-bridges on End-Systems
The explanation above did not indicate how a transport
connection was redirected to a particular TS-bridge.
Depending on the approach taken, varying levels of
transparency can be achieved in the end-systems.
One solution requires knowledge of the TS-bridge in the
initiating end-system; further, such a solution requires that
the initiating end-system act in a non-standard fashion in
order to establish a connection when using a TS-bridge.
In contrast, another solution might rely on a rich OSI
network-layer infrastructure so as to achieve the "ES-
transparency" effect: no local knowledge of TS-bridges should
exist at an end-system; further, use of a TS-bridge should not
result in non-standard behavior at an end-system.
M.T. Rose (editor) [Page 10]
Internet Draft CO/CL Interworking -- Introduction Apr 91
5.4. Impact of TS-bridges on the Transport Service
It should be noted that transport-layer relays suffer from (at
least) four weaknesses:
(1) A transport-layer relay maintains state for its two
existing connections, and is therefore a single point of
failure. For example, if the relay fails, the transport
connections between the end-systems will fail, even
though both end-systems are operational and an
alternative path is available.
(2) Use of a transport-layer relay defeats the end-to-end
integrity property of the TS-stack. Note that user-data
passes through the relay in transit between the two TS-
stacks. This data might be corrupted if the relay is
faulty.
Similarly, use of a transport-layer relay defeats any
transport-level encrypt mechanisms as the data appears in
the clear inside the relay. (Of course, encryption could
occur at a higher layer to retain privacy.)
(3) Use of a transport-layer relay may introduce additional
variability in round-trip times due to buffering in the
relay. (The implications of this effect are not known.)
(4) Finally, depending on how use of the transport-layer
relay is integrated with the end-systems, end-to-end
addresses may not be carried transparently. For example,
in the short-term, the responding end-system sees the
network address of the transport-layer relay as the
calling address, instead of the address of the actual
originator.
M.T. Rose (editor) [Page 11]
Internet Draft CO/CL Interworking -- Introduction Apr 91
6. Towards a Solution
In the best solution, there is a single mode of OSI network
service which is truly ubiquitous. In this case, a single
community exists and interworking is achieved through the use
of network-layer relays. In preparation for this long-term
scenario, technology must be identified and perhaps
incrementally advanced to promote a homogeneous network
service. In the meantime, a large TCP/IP-based community
exists and a TP0/CONS community is growing. Some interworking
requirements exist today and these requirements are expected
to increase. This suggests a short-term solution to address
immediate requirements, an intermediate-term solution
applicable as the TP0/CONS community grows large, and a long-
term solution applicable once two large OSI communities, one
CO-mode and the other CL-mode, exist and have interworking
requirements.
Thus, an approach towards the solution consists of two parts,
and two companion memos have been been written, each
corresponding to the short-term and long-term:
In the short-term, one must rely on TS-bridges to provide
connectivity between non-internetworking communities. The
first companion memo, [6], describes the operation of TS-
bridges in such an environment.
The fundamental component of the long-term is the use of
network-layer relays, supporting either the CO- or CL-mode OSI
network service. Use of network-layer relays is well-
understood. However, even in the long-term, situations will
arise in which both network services are required. In this
case, TS-bridges are still necessary. The second companion
memo, [7], describes the operation of TS-bridges in such an
environment.
M.T. Rose (editor) [Page 12]
Internet Draft CO/CL Interworking -- Introduction Apr 91
7. Acknowledgements
The first version of this memo was produced by the CO/CL
Interworking Workshop, which met on July 24-26, 1990:
Les Clyne, JNT
Walid Dabbous, INRIA
Phill Gross, NRI
Christian Huitema, INRIA
Steve Kille, UCL
Kevin Mills, NIST
Julian Onions, Nottingham University
Marshall Rose, PSI
Rachid Sijelmassi, NIST
Mitchell Tasman, University of Wisconsin
There were several contributions which led to the development
of the approach described in this memo:
In "CO-CL and TCP/IP Interworking and Coexistence", Mills
suggested that the problem can be solved by using a single
mode of network service (CLNS), and further that
interoperability with TCP/IP-based environments would occur
through the use of application gateways.
In "A Survey of Solutions to the Connectionless/Connection-
mode and the OSI/DoD Interworking Problems", West and
Sijelmassi outlined the various approaches and assigned
comparative metrics.
The ISO/IEC Draft Technical Report 10172 (SC 6 N 5906)
outlined a framework for transport-layer relaying.
In "Implementation Agreements for Transport Service Bridges",
Rose outlined the basic model of transport-layer relaying and
proposed the basis for an approach in the short-term.
In "An ISO TP4-TP0 Gateway", Landweber and Tasman described an
implementation of a TS-bridge.
In "An NSAP approach to build transport OSI transport bridges,
Huitema and Dabbous described how ES-transparency can be
achieved, and in "Extension of OSI TP4 to support transport
bridging", they described modifications to the TP4 protocol to
aid in achieving the ES-transparency effect.
M.T. Rose (editor) [Page 13]
Internet Draft CO/CL Interworking -- Introduction Apr 91
8. References
[1] International Organization for Standardization.
Information Processing Systems--Open Systems
Interconnection--Transport Service Definition.
International Standard 8072. (June, 1986).
[2] International Organization for Standardization.
Information Processing Systems--Data Communications--
Network Service Definition. International Standard 8348.
(April, 1987).
[3] International Organization for Standardization.
Information Processing Systems--Data Communications--
Network Service Definition--Addendum 1: Connectionless-
mode Transmission. International Standard 8348/AD 1.
(April, 1987).
[4] M.T. Rose and D.E. Cass. ISO Transport Services on top
of the TCP. Internet Working Group Request for Comments
1006. Network Information Center, SRI International,
Menlo Park, California, (May, 1987).
[5] S.E. Kille. An interim approach to use of Network
Addresses. Research Note RN/89/13. Department of
Computer Science, University College London, (February,
1989).
[6] M.T. Rose (editor). An Approach to CO/CL Interworking --
Part II: The Short-Term -- Conventions for Transport-
Service Bridges in the absence of Internetworking, CO/CL
Interworking Workshop, (July, 1990).
[7] C. Huitema (editor). An Approach to CO/CL Interworking:
-- Part III: The Long-Term -- Conventions for Network-
Layer Relays and Transport-Service Bridges in the
presence of Internetworking, CO/CL Interworking Workshop,
(July, 1990).
M.T. Rose (editor) [Page 14]
Internet Draft CO/CL Interworking -- Introduction Apr 91
Table of Contents
1 Status of this Memo ................................... 1
2 Introduction .......................................... 2
2.1 An Aside ............................................ 2
3 Application Use of End-to-End Services ................ 3
3.1 Emulation of OSI End-to-End Services ................ 4
4 Problems in Realizing the Model ....................... 6
5 Transport-Service Bridges ............................. 8
5.1 State Machine ....................................... 9
5.2 Parameters for the second connection ................ 9
5.3 Impact of TS-bridges on End-Systems ................. 10
5.4 Impact of TS-bridges on the Transport Service ....... 11
6 Towards a Solution .................................... 12
7 Acknowledgements ...................................... 13
8 References ............................................ 14
M.T. Rose (editor) [Page 15]
------- End of Forwarded Message
